.vs/TaskManagement.slnx/v18/DocumentLayout.json (1)

3-68: ⚠️ Potential issue | 🟠 Major

Local path and activity metadata leaked via tracked IDE layout file.

This file persists machine-specific paths and timestamps (for example, Line 3 and Lines 41/54/67). It should not be committed. Please remove tracked .vs layout artifacts and keep .vs/ ignored.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.vs/TaskManagement.slnx/v18/DocumentLayout.json around lines 3 - 68, The
repo contains a tracked IDE layout JSON (DocumentLayout.json) that leaks
machine-specific keys like "WorkspaceRootPath" and timestamp fields
"WhenOpened"; remove that file from version control, add the IDE layout
directory/pattern to .gitignore (so future files aren’t tracked), and commit the
change; specifically run git rm --cached on the tracked DocumentLayout.json
entry (or equivalent) and commit the removal alongside updating .gitignore to
ignore the IDE layout files.

.vs/TaskManagement.slnx/v18/DocumentLayout.backup.json (1)

1-33: ⚠️ Potential issue | 🟠 Major

Same issue: local IDE backup layout should not be tracked.

This backup file is user-specific workspace metadata and includes absolute local paths (for example, Line 3). Please remove it from git and rely on .gitignore for .vs/.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.vs/TaskManagement.slnx/v18/DocumentLayout.backup.json around lines 1 - 33,
This file contains user-specific IDE workspace metadata (e.g., the
"WorkspaceRootPath" entry) and should not be tracked; remove .vs/ layout backups
from the repo by deleting this file from Git tracking (use git rm --cached on
this DocumentLayout.backup.json or equivalent), add/ensure `.vs/` is listed in
.gitignore, and commit the change so future workspace files (including entries
like "WorkspaceRootPath") are not committed.

.vs/VSWorkspaceState.json-1-13 (1)

1-13: ⚠️ Potential issue | 🟠 Major

Do not commit .vs workspace state files.

This is local machine/editor state (for example, Line 11 selected node) and will create persistent merge noise across developers. Please remove this file from version control and ignore .vs/ in .gitignore.

Suggested cleanup

# .gitignore
+.vs/

- .vs/VSWorkspaceState.json

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.vs/VSWorkspaceState.json around lines 1 - 13, The committed .vs workspace
state (VSWorkspaceState.json containing keys like "ExpandedNodes" and
"SelectedNode") is local editor state and must be removed from version control:
delete the tracked .vs/VSWorkspaceState.json from the repo, add the .vs/
directory (or .vs/) to .gitignore, remove the file from the git index (so it
stops being tracked) and commit the .gitignore and removal; ensure future
commits do not re-add VSWorkspaceState.json by verifying .gitignore contains the
.vs/ pattern.

src/web/index.html-24-24 (1)

24-24: ⚠️ Potential issue | 🟠 Major

Use apple-mobile-web-app-capable for iOS Safari/PWA support.

Line 24 currently uses mobile-web-app-capable, which is the Android/Chromium standard. The iOS-specific meta tag is apple-mobile-web-app-capable. Since this line is within the "iOS meta tags" section (alongside other apple-* prefixed tags), it should be corrected to ensure iOS home screen web apps function properly in standalone mode.

Suggested fix

-  <meta name="mobile-web-app-capable" content="yes">
+  <meta name="apple-mobile-web-app-capable" content="yes">

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/web/index.html` at line 24, Replace the Android/Chromium meta tag name
"mobile-web-app-capable" with the iOS-specific name
"apple-mobile-web-app-capable" in the iOS meta tags section so the line that
currently sets mobile-web-app-capable to "yes" uses the apple-prefixed meta name
to enable proper iOS Safari/PWA standalone behavior.

src/lib/features/chatbot/model/chatmessage_model.dart-14-23 (1)

14-23: ⚠️ Potential issue | 🟠 Major

Make persisted chat history decoding tolerant of bad data.

jsonDecode(raw), Map<String, dynamic>.from(item), and json['isUser'] as bool? can throw for corrupted or older persisted data, which can break chat startup instead of falling back to an empty/partial history.

Suggested hardening

   factory ChatMessageModel.fromJson(Map<String, dynamic> json) {
     final parsedTimestamp =
         DateTime.tryParse(json['timestamp']?.toString() ?? '') ?? DateTime.now();
+    final rawIsUser = json['isUser'];

     return ChatMessageModel(
       text: json['text']?.toString() ?? '',
-      isUser: json['isUser'] as bool? ?? true,
+      isUser: rawIsUser is bool ? rawIsUser : true,
       timestamp: parsedTimestamp,
     );
   }
@@
   static List<ChatMessageModel> decodeList(String raw) {
-    final decoded = jsonDecode(raw);
-    if (decoded is! List) return [];
-
-    return decoded
-        .whereType<Map>()
-        .map((item) => ChatMessageModel.fromJson(Map<String, dynamic>.from(item)))
-        .toList();
+    try {
+      final decoded = jsonDecode(raw);
+      if (decoded is! List) return [];
+
+      final messages = <ChatMessageModel>[];
+      for (final item in decoded.whereType<Map>()) {
+        try {
+          messages.add(
+            ChatMessageModel.fromJson(Map<String, dynamic>.from(item)),
+          );
+        } catch (_) {
+          // Skip malformed entries instead of failing the whole history load.
+        }
+      }
+      return messages;
+    } catch (_) {
+      return [];
+    }
   }

Also applies to: 37-45

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/chatbot/model/chatmessage_model.dart` around lines 14 - 23,
The ChatMessageModel.fromJson should be made defensive so corrupted/old
persisted data doesn't throw: wrap parsing in a try/catch and fall back to sane
defaults, avoid using direct casts like json['isUser'] as bool? and Map<String,
dynamic>.from; instead tolerate null/malformed json by checking types and
coercing values (e.g., accept 'true'/'false' strings or 1/0 for isUser, parse
timestamp with DateTime.tryParse and default to DateTime.now() on failure), and
catch any exceptions to return a ChatMessageModel with safe defaults; apply the
same hardening to the corresponding alternate constructor/decoder referenced
around lines 37-45 (the other ChatMessageModel factory/decoder) so all persisted
history decoding is tolerant of bad data.

src/lib/features/category/view/widgets/category_choice_chips.dart-37-40 (1)

37-40: ⚠️ Potential issue | 🟠 Major

Choose selected label color based on chip background contrast.

Line 40 hardcodes white text for every selected category. Light category colors can make the selected chip label unreadable.

Suggested contrast-aware fix

           final category = categories[index];
           final adaptiveColor = category.color.toAdaptiveColor(context);
           final isSelected = category.id == selectedCategoryId;
+          final selectedLabelColor =
+              ThemeData.estimateBrightnessForColor(adaptiveColor) ==
+                      Brightness.dark
+                  ? Colors.white
+                  : Colors.black;
           return Padding(
@@
               selectedColor: adaptiveColor,
               labelStyle: TextStyle(
-                color: isSelected ? Colors.white : adaptiveColor,
+                color: isSelected ? selectedLabelColor : adaptiveColor,
                 fontSize: 14,
               ),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/category/view/widgets/category_choice_chips.dart` around
lines 37 - 40, The selected label color is hardcoded to Colors.white which can
be unreadable on light selected chip backgrounds; update the label color logic
in the widget that builds the ChoiceChip (referenced by labelStyle,
backgroundColor, selectedColor, isSelected and adaptiveColor) to pick a
contrast-aware color when isSelected is true (e.g., use
adaptiveColor.computeLuminance() to choose Colors.white for dark backgrounds and
Colors.black for light backgrounds) while keeping the current adaptiveColor for
the unselected state.

src/lib/features/category/viewmodel/category_viewmodel.dart-22-38 (1)

22-38: ⚠️ Potential issue | 🟠 Major

Guard against stale overlapping category loads.

loadCategories() can be triggered from multiple screens. If two calls overlap, the older request can finish last and overwrite newer data/error state, and _isLoading can flip to false while another request is still running.

Suggested request-token guard

   String? _error;
   String? get error => _error;
+
+  int _loadRequestId = 0;

   Future<void> loadCategories() async {
+    final requestId = ++_loadRequestId;
     _isLoading = true;
     _error = null;
     notifyListeners();

     try {
       final data = await _repository.fetchCategories();
+      if (requestId != _loadRequestId) return;
       _categories
         ..clear()
         ..addAll(data);
     } catch (e) {
+      if (requestId != _loadRequestId) return;
       _error = e.toString();
       _categories.clear();
     } finally {
+      if (requestId != _loadRequestId) return;
       _isLoading = false;
       notifyListeners();
     }
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/category/viewmodel/category_viewmodel.dart` around lines 22
- 38, loadCategories can suffer from race conditions when multiple overlapping
calls overwrite state; introduce a request token/id (e.g., _currentLoadId or
_loadToken) that you increment before calling _repository.fetchCategories(),
capture locally inside loadCategories(), and only apply results to _categories,
_error and set _isLoading=false if the captured token equals the latest token;
alternatively use an _activeLoadCount++/-- to keep _isLoading true while any
load remains active. Update loadCategories to increment the token (or active
count) before await, check the token after await (or decrement active count in
finally) and only mutate state when the token matches (or active count hits
zero), so older requests cannot overwrite newer results.

src/lib/features/main/view/screens/create_task.dart-72-81 (1)

72-81: ⚠️ Potential issue | 🟠 Major

Do not collect fields that are discarded on save.

The screen accepts description and endTime, but the insert only persists title/category/start timestamp. This silently loses user-entered task details; either persist these fields through the supported schema/RPC or remove the inputs until they are supported.

Also applies to: 140-145, 279-316

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/main/view/screens/create_task.dart` around lines 72 - 81,
The form collects description and endTime but the insert (via
_supabase.from('task').insert) only saves title/category/create_at, causing
silent data loss; either persist the extra fields by adding the correct column
names to the insert payload (e.g., include 'description': _description.trim()
and the proper timestamp column like 'end_at' or 'end_time':
endTime.toIso8601String() matching your DB/RPC schema) and update any RPC calls
used in _createTask/_saveTask methods, or remove/disable the description and
endTime inputs from the CreateTask screen so the UI matches what is actually
persisted (also apply the same fix to the other create/update blocks in this
file that handle task inserts/updates).

src/lib/features/main/view/screens/create_task.dart-54-61 (1)

54-61: ⚠️ Potential issue | 🟠 Major

Resolve categories from persisted data instead of hard-coded IDs.

Mapping display labels to fixed IDs can create tasks under the wrong category when database IDs differ between environments or users. Use the loaded category model/RPC result and submit the selected category’s actual ID.

Also applies to: 207-239

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/main/view/screens/create_task.dart` around lines 54 - 61,
The code currently maps labels to hard-coded IDs using categoryMapping and
assigns categoryId from _selectedCategory; instead, look up the persisted
Category model returned by your RPC/fetch (e.g., the list variable that holds
loaded categories such as fetchedCategories or categories) and find the matching
category by its display label (or unique key) and use that Category.id when
creating the task; replace the hard-coded categoryMapping and fallback logic so
creation uses the real persisted ID and add a safe fallback (e.g., use the first
category id or surface a validation error) if no match is found.

src/pubspec.yaml-47-47 (1)

47-47: ⚠️ Potential issue | 🟠 Major

Move the Gemini API key to a backend service instead of bundling it in the Flutter app.

The chatbot service loads GEMINI_API_KEY from the bundled .env asset file. Since Flutter assets are extractable from the app package, this exposes the API key to any user who inspects the app. Use a Supabase Edge Function or other backend proxy to handle Gemini API calls instead.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pubspec.yaml` at line 47, Remove GEMINI_API_KEY from the bundled .env
asset and stop initializing the chatbot service with a client-side Gemini key;
instead implement a backend proxy (e.g., a Supabase Edge Function) that stores
the Gemini API key securely and exposes an authenticated endpoint for chat
requests, update the client-side ChatbotService (or wherever GEMINI_API_KEY is
read) to call that backend endpoint (e.g., /edge-fn/gemini-chat) for all Gemini
interactions, and ensure build/config no longer includes google_generative_ai
credentials in assets or source so the key is never packaged with the Flutter
app.

src/lib/features/main/view/screens/main_screen.dart-38-42 (1)

38-42: ⚠️ Potential issue | 🟠 Major

useMockData: true is hard-coded in production initialization.

UserProfileViewModel(useMockData: true) is being wired into the live app shell at line 39. The constructor defaults to true, but here it is explicitly set, ensuring the profile tab always loads mock data (via _buildMockUser()) instead of real user data from UserService.fetchUserProfile(). This defeats the purpose of the UserService integration added in this PR.

Before merging, gate this behind a build flag (kDebugMode, environment variable, or --dart-define) so production builds use real data.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/main/view/screens/main_screen.dart` around lines 38 - 42,
The UserProfileViewModel is being initialized with useMockData: true in the
production app shell; change the initialization of UserProfileViewModel in the
widget tree so useMockData is driven by a build-time/debug flag (e.g., use
kDebugMode or a bool from environment via bool.fromEnvironment/--dart-define)
instead of hard-coding true so that in production the constructor uses the real
UserService.fetchUserProfile(); update the create call that constructs
UserProfileViewModel (and its subsequent loadProfile()) to pass useMockData:
<flag> (or omit if defaulting appropriately) and ensure UserProfileView remains
untouched.

src/lib/main.dart-36-49 (1)

36-49: ⚠️ Potential issue | 🟠 Major

Don’t surface exception + stack trace in release builds.

ErrorWidget.builder is set unconditionally, so production users will see raw exception messages and stack traces on widget build failures. This is both a poor UX and a potential information-disclosure vector (internal paths, package names, SQL-looking messages from Supabase, etc.).

Proposed fix — gate on `kDebugMode`

-  ErrorWidget.builder = (FlutterErrorDetails details) {
-    return Material(
-      child: Container(
-        color: Colors.black87,
-        padding: const EdgeInsets.all(20),
-        child: SingleChildScrollView(
-          child: Text(
-            'Lỗi!\n\n${details.exception}\n\nStack Trace:\n${details.stack}',
-            style: const TextStyle(color: Colors.greenAccent, fontSize: 14),
-          ),
-        ),
-      ),
-    );
-  };
+  if (kDebugMode) {
+    ErrorWidget.builder = (FlutterErrorDetails details) {
+      return Material(
+        child: Container(
+          color: Colors.black87,
+          padding: const EdgeInsets.all(20),
+          child: SingleChildScrollView(
+            child: Text(
+              'Lỗi!\n\n${details.exception}\n\nStack Trace:\n${details.stack}',
+              style: const TextStyle(color: Colors.greenAccent, fontSize: 14),
+            ),
+          ),
+        ),
+      );
+    };
+  }

Requires import 'package:flutter/foundation.dart';.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/main.dart` around lines 36 - 49, ErrorWidget.builder is currently set
unconditionally and exposes raw exceptions/stack traces from FlutterErrorDetails
in production; wrap the custom ErrorWidget.builder assignment in a kDebugMode
check (importing package:flutter/foundation.dart) so the detailed error UI is
only used in debug, and provide a safe generic user-friendly fallback for
release builds (e.g., a simple error message or empty Container) to avoid
leaking internals.

src/lib/features/user/service/user_service.dart-10-24 (1)

10-24: ⚠️ Potential issue | 🟠 Major

Double-wrapped exception handling obscures the original error in debug logs.

The try/catch block at lines 10–23 wraps every thrown Exception — including the two Exception instances thrown inside the try block at lines 13 and 17 — into a generic Exception("Failed to fetch user profile: $e"). The resulting debug message becomes "Error loading profile: Exception: Failed to fetch user profile: Exception: Không tìm thấy...", burying the original exception type and losing the stack trace.

Either drop the outer try/catch entirely (let callers surface the original error) or use rethrow to preserve the trace.

Additionally, remove the stale comments on lines 7 and 9 (which claim to "simulate" and "mimic" a network delay, but the code performs real API calls without any artificial delay), and reuse the already-loaded user.id instead of redundantly calling currentUser!.id again on line 19.

Proposed fix

-  Future<UserProfileModel> fetchUserProfile() async {
-    // Mimic API call delay for smooth state switching
-    try{
-      final user = _supabase.auth.currentUser;
-      if (user == null) {
-        throw Exception("Không tìm thấy phiên đăng nhập. Hãy đăng nhập lại");
-      }
-      final response = await _supabase.rpc('get_user_profile_stats');
-      if(response == null){
-        throw Exception("Không thể lấy thông tin người dùng. Hãy thử lại sau");
-      }
-      response['id'] = _supabase.auth.currentUser!.id;
-      return UserProfileModel.fromJson(response);
-    }
-    catch(e){
-      throw Exception("Failed to fetch user profile: $e");
-    }
-  }
+  Future<UserProfileModel> fetchUserProfile() async {
+    final user = _supabase.auth.currentUser;
+    if (user == null) {
+      throw Exception('Không tìm thấy phiên đăng nhập. Hãy đăng nhập lại');
+    }
+    final response = await _supabase.rpc('get_user_profile_stats');
+    if (response == null) {
+      throw Exception('Không thể lấy thông tin người dùng. Hãy thử lại sau');
+    }
+    final map = Map<String, dynamic>.from(response as Map);
+    map['id'] = user.id;
+    return UserProfileModel.fromJson(map);
+  }

This also defensively copies the RPC response into a new Map<String, dynamic> before mutating, in case the returned map is immutable.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/user/service/user_service.dart` around lines 10 - 24, The
catch block in the user profile fetch wraps and masks original exceptions;
remove the outer try/catch or replace the catch with a rethrow to preserve stack
traces, reuse the already-loaded user variable for the id (use user.id instead
of calling _supabase.auth.currentUser!.id), defensively copy the RPC result into
a new Map<String, dynamic> before mutating (so you don’t modify an immutable
response) and remove the stale "simulate"/"mimic" network delay comments; locate
changes around the _supabase usage and UserProfileModel.fromJson call to update
error handling, response copying, and id assignment.

supabase/migrations/20260417060333_chatbot_add_task_rpc.sql-46-50 (1)

46-50: ⚠️ Potential issue | 🟠 Major

Avoid returning raw database errors to clients.

SQLERRM can expose table names, constraint names, and policy details. Return a stable error code/message and log the internal error server-side.

Proposed fix

 EXCEPTION WHEN OTHERS THEN
+  RAISE LOG 'create_task_full failed for user %: %', auth.uid(), SQLERRM;
   RETURN json_build_object(
     'success', false,
-    'error', SQLERRM
+    'error', 'CREATE_TASK_FAILED'
   );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@supabase/migrations/20260417060333_chatbot_add_task_rpc.sql` around lines 46
- 50, The EXCEPTION WHEN OTHERS THEN block currently returns raw SQLERRM via
json_build_object which can leak internal schema details; change this to log the
full SQLERRM/server error internally (e.g., RAISE NOTICE/EXCEPTION to a server
log, INSERT into an audit/errors table, or call a logging function) and return a
stable, non-sensitive payload instead (e.g., json_build_object('success', false,
'code', 'INTERNAL_ERROR', 'message', 'An unexpected error occurred')). Update
the EXCEPTION WHEN OTHERS THEN handling that references SQLERRM and
json_build_object to perform internal logging and return the generic error
object.

src/lib/features/tag/view/widgets/tag_selector.dart-24-59 (1)

24-59: ⚠️ Potential issue | 🟠 Major

Pop the dialog context, not the parent context, after async work.

If the user dismisses the dialog while addCustomTag is pending, Navigator.pop(context) can pop the underlying screen. Capture the dialog context and check that it is still mounted.

Proposed fix

     showDialog(
       context: context,
-      builder: (_) => AlertDialog(
+      builder: (dialogContext) => AlertDialog(
@@
           TextButton(
-            onPressed: () => Navigator.pop(context),
+            onPressed: () => Navigator.pop(dialogContext),
             child: const Text('Huỷ'),
           ),
@@
               if (error != null) {
                 ScaffoldMessenger.of(context).showSnackBar(
@@
                 );
               } else {
-                Navigator.pop(context);
+                if (dialogContext.mounted) {
+                  Navigator.pop(dialogContext);
+                }
               }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/tag/view/widgets/tag_selector.dart` around lines 24 - 59,
The dialog is popping the parent context after awaiting viewModel.addCustomTag;
update _showAddCustomDialog to capture the dialog-specific BuildContext by
changing the showDialog builder signature to (dialogContext) => AlertDialog(...)
and replace Navigator.pop(context) inside the async handler with
Navigator.of(dialogContext).pop(), but only after verifying the dialog navigator
is still mounted (e.g., if (Navigator.of(dialogContext).mounted)
Navigator.of(dialogContext).pop()); keep references to _showAddCustomDialog and
viewModel.addCustomTag to locate the changes.

supabase/migrations/20260413084521_update_user_profile_with_heatmap_rpc.sql-6-35 (1)

6-35: ⚠️ Potential issue | 🟠 Major

Clamp p_days and compare local dates consistently.

A caller can pass a huge p_days value and force a large scan. Also, the current updated_at >= (...)::DATE comparison converts a Vietnam-local date back through the DB timezone, which can drop boundary-day completions.

Proposed fix

 DECLARE
     v_user_id UUID;
     v_username TEXT;
     v_avatar TEXT;
     v_tasks_done INT;
     v_current_streak INT;
     v_heatmap_data JSON;
+    v_days INT;
 BEGIN
     v_user_id := auth.uid();
+    v_days := LEAST(GREATEST(COALESCE(p_days, 90), 1), 365);
 
     IF v_user_id IS NULL THEN
         RAISE EXCEPTION 'User not authenticated';
@@
         SELECT DATE(updated_at AT TIME ZONE 'Asia/Ho_Chi_Minh') AS task_date, COUNT(*) AS task_count
         FROM public.task
         WHERE profile_id = v_user_id AND status = 1
-          AND updated_at >= ((CURRENT_TIMESTAMP AT TIME ZONE 'Asia/Ho_Chi_Minh')::DATE - (p_days || ' days')::INTERVAL)
+          AND DATE(updated_at AT TIME ZONE 'Asia/Ho_Chi_Minh')
+              >= (CURRENT_TIMESTAMP AT TIME ZONE 'Asia/Ho_Chi_Minh')::DATE - v_days
         GROUP BY DATE(updated_at AT TIME ZONE 'Asia/Ho_Chi_Minh')

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@supabase/migrations/20260413084521_update_user_profile_with_heatmap_rpc.sql`
around lines 6 - 35, Clamp the incoming p_days to a safe range (e.g., min 1, max
365) and use that clamped value when building the interval; replace direct
(p_days || ' days')::INTERVAL with a sanitized integer (e.g., v_days) and use
INTERVAL format based on that value. Also compare dates in the same local
timezone by converting updated_at to 'Asia/Ho_Chi_Minh' and comparing its DATE
to (CURRENT_TIMESTAMP AT TIME ZONE 'Asia/Ho_Chi_Minh')::DATE - v_days (or
equivalent interval), so the WHERE clause that computes task_date
(DATE(updated_at AT TIME ZONE 'Asia/Ho_Chi_Minh')) is compared against a local
DATE boundary computed the same way to avoid timezone boundary drops; update
references in the heatmap query that produce v_heatmap_data and any earlier uses
of p_days accordingly.

src/lib/features/statistics/view/widgets/statistics_widgets.dart-344-351 (1)

344-351: ⚠️ Potential issue | 🟠 Major

Handle TimeOfDay rollover at 23:xx.

task.updatedAt.hour + 1 becomes 24 for tasks completed at 23:xx, which is outside Flutter's valid TimeOfDay hour range (0–23). The code at line 349 will throw a runtime error when a task is updated at this time.

Proposed fix

           onTap: () {
+            final endDateTime = task.updatedAt.add(const Duration(hours: 1));
             final mappedTask = TaskModel(
@@
               endTime: TimeOfDay(
-                hour: task.updatedAt.hour + 1,
-                minute: task.updatedAt.minute,
+                hour: endDateTime.hour,
+                minute: endDateTime.minute,
               ),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/statistics/view/widgets/statistics_widgets.dart` around
lines 344 - 351, The endTime construction can produce an invalid hour (24) when
task.updatedAt.hour is 23; update the TimeOfDay creation to wrap hours into the
valid 0–23 range (e.g., compute endHour = (task.updatedAt.hour + 1) % 24 or
conditional if task.updatedAt.hour == 23 then 0) and use that endHour with
task.updatedAt.minute when building the endTime TimeOfDay to avoid runtime
errors in TimeOfDay(hour: ..., minute: ...).

src/lib/features/tasks/view/screens/home_screen.dart-105-109 (1)

105-109: ⚠️ Potential issue | 🟠 Major

Theming regression: hardcoded AppColors/Colors.black/Colors.white across the screen.

The stated intent of this PR is a theme refactor, but HomeScreen still hardcodes brand/system colors in several spots, so the screen renders poorly in dark mode and bypasses the new ColorScheme:

• Line 109: Container(color: AppColors.primaryBlue) for the top wave — should use Theme.of(context).colorScheme.primary.
• Lines 170, 173, 181: Icon(..., color: Colors.black) for menu/notifications/add — invisible on dark backgrounds; use colorScheme.onSurface (or onPrimary if the wave sits behind them).
• Line 224: AppColors.grayText → colorScheme.onSurfaceVariant.
• Line 268: _FilterChip(color: AppColors.primaryBlue, ...) — should use colorScheme.primary.
• Lines 389, 398: _FilterChip uses Colors.white for unselected bg / selected text — breaks in dark mode; prefer colorScheme.surface / colorScheme.onPrimary.

Once these are removed, the app_colors.dart import on Line 5 should go too.

Also applies to: 167-199, 223-224, 265-270, 385-400

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/tasks/view/screens/home_screen.dart` around lines 105 - 109,
HomeScreen still uses hardcoded AppColors/Colors (e.g., Container(color:
AppColors.primaryBlue) in the TopWaveClipper area, Icon(..., color:
Colors.black), AppColors.grayText, and _FilterChip(color:
AppColors.primaryBlue/Colors.white)), which breaks dark mode; update these
usages to read from Theme.of(context).colorScheme (use colorScheme.primary for
the wave and _FilterChip selected color, colorScheme.onPrimary for icons on the
wave, colorScheme.onSurface/onSurfaceVariant for surface text/icons, and
colorScheme.surface for chip backgrounds) and adjust _FilterChip props
accordingly so selected/unselected states use colorScheme.surface and
colorScheme.onPrimary/onSurface as appropriate; after replacing all occurrences
in HomeScreen and _FilterChip, remove the unused app_colors.dart import.

src/lib/features/tasks/view/screens/task_detail_screen.dart-220-250 (1)

220-250: ⚠️ Potential issue | 🟠 Major

Delete flow uses a popped context and ignores async failures.

Three issues on the delete path:

1. context.read<TaskViewModel>().deleteTask(widget.task.id) is not awaited, so Navigator.pop(context) runs before the delete completes; if the RPC fails, the task is already removed from the UI stack and the error is swallowed.
2. ScaffoldMessenger.of(context).showSnackBar(...) at Line 240 is called AFTER Navigator.pop(context) at Line 239 — the detail screen is being torn down, so the snackbar frequently shows on the wrong scaffold or not at all.
3. No mounted check after the async work.

Await the delete, capture the messenger before popping, and show the snackbar via the parent scaffold.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/tasks/view/screens/task_detail_screen.dart` around lines 220
- 250, The delete path should await the async delete, capture the
ScaffoldMessenger before popping, and check mounted before navigating: change
the onPressed handler inside the AlertDialog's "Xóa" button to await
context.read<TaskViewModel>().deleteTask(widget.task.id) (referencing
TaskViewModel.deleteTask and widget.task.id), call final messenger =
ScaffoldMessenger.of(context) before any Navigator.pop calls, then after the
await verify if (!mounted) return; before calling Navigator.pop(context) and
Navigator.pop(ctx); use messenger.showSnackBar(...) to show success or show an
error SnackBar if the awaited delete throws (catch the exception and show a
failure message) so the UI isn't popped prematurely and snackbar targets the
correct scaffold.

src/lib/features/chatbot/services/chatbot_services.dart-72-104 (1)

72-104: ⚠️ Potential issue | 🟠 Major

Unsafe casts and unvalidated RPC inputs; catch-all hides real failures as "AI connection error".

A few concerns in the function-call branch:

• Line 76: args['title'] as String will throw if Gemini returns null or a non-string for title. Any such failure propagates to the generic catch (e) at Line 106 and is reported to the user as Lỗi kết nối AI: …, which is misleading (it's a schema violation, not a network error).
• Line 77: priority is clamped via ?? 1 but not range-checked. The RPC create_task_full accepts any INT4 and stores it as-is, so a model hallucination like priority: 99 silently corrupts task data. Clamp to [1, 3] before calling the RPC.
• Line 96: dbResponse['success'] assumes the RPC response is a Map. Supabase rpc(...) returns dynamic; if the function errors out or returns null, this throws and again surfaces as a connection error.
• Line 98: Sending a functionResponse with only {'status': 'Thành công' | 'Thất bại'} drops the RPC's error/task_id/message fields, so the model cannot tailor its reply (or apologize with a reason on failure). Forward the relevant payload.

🛡️ Proposed hardening

-          final title = args['title'] as String;
-          final priority = (args['priority'] as num?)?.toInt() ?? 1;
-          final rawTags = args['tags'] as List<dynamic>? ?? [];
-          final tags = rawTags.map((e) => e.toString()).toList();
+          final title = (args['title'] as String?)?.trim() ?? '';
+          if (title.isEmpty) {
+            return 'Mình chưa rõ tên công việc, bạn nói lại giúp nhé!';
+          }
+          final rawPriority = (args['priority'] as num?)?.toInt() ?? 1;
+          final priority = rawPriority.clamp(1, 3);
+          final rawTags = args['tags'] as List<dynamic>? ?? const [];
+          final tags = rawTags.map((e) => e.toString()).toList();
@@
-          final isSuccess = dbResponse['success'] == true;
+          final responseMap = (dbResponse is Map) ? dbResponse : const {};
+          final isSuccess = responseMap['success'] == true;
           final functionResponse = await _chatSession!.sendMessage(
             Content.functionResponse('create_task_full', {
-              'status': isSuccess ? 'Thành công' : 'Thất bại',
+              'status': isSuccess ? 'Thành công' : 'Thất bại',
+              if (!isSuccess && responseMap['error'] != null)
+                'error': responseMap['error'],
             }),
           );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/chatbot/services/chatbot_services.dart` around lines 72 -
104, In the function-call branch handling response.functionCalls (inside the
block that checks functionCall.name == 'create_task_full'), validate and safely
parse args: ensure title is a non-empty String (return a clear user-facing
validation message if missing), parse priority as int then clamp it to the
allowed range 1..3, and coerce tags to List<String> safely; then call
Supabase.instance.client.rpc with these sanitized inputs. After RPC, defensively
handle dbResponse being null or not a Map (check type and presence of keys),
extract and forward relevant RPC fields (e.g., 'success', 'task_id', 'message',
'error') into the Content.functionResponse payload instead of only {'status':
...} so the model gets full context, and ensure any thrown parsing/validation
errors are reported with an appropriate message rather than bubbled to the
generic AI-connection catch-all; update the use of
_chatSession!.sendMessage(Content.functionResponse('create_task_full', ...))
accordingly.

src/lib/features/tasks/view/screens/task_detail_screen.dart-130-157 (1)

130-157: ⚠️ Potential issue | 🟠 Major

FutureBuilder.future recreated on every rebuild.

future: context.read<TaskViewModel>().getNotesForTask(taskId) is evaluated inline, so every rebuild of the detail screen (tag toggle, category change, time picker, keyboard open/close, etc.) kicks off a new Supabase query and briefly shows CircularProgressIndicator, causing flicker and unnecessary network traffic. Store the Future in state and only refresh it in response to explicit events (e.g., after createNote succeeds).

♻️ Sketch

-class _TaskDetailScreenState extends State<TaskDetailScreen> {
+class _TaskDetailScreenState extends State<TaskDetailScreen> {
+  Future<List<NoteModel>>? _notesFuture;
@@
-    _currentTags = List.from(widget.task.tags);
+    _currentTags = List.from(widget.task.tags);
+    _notesFuture = context.read<TaskViewModel>().getNotesForTask(widget.task.id.toString());
@@
-        FutureBuilder<List<NoteModel>>(
-          future: context.read<TaskViewModel>().getNotesForTask(taskId),
+        FutureBuilder<List<NoteModel>>(
+          future: _notesFuture,

Then refresh _notesFuture after a successful createNote instead of calling bare setState(() {}).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/tasks/view/screens/task_detail_screen.dart` around lines 130
- 157, The FutureBuilder is recreating the future each rebuild because you call
context.read<TaskViewModel>().getNotesForTask(taskId) inline; introduce a State
field (e.g., Future<List<NoteModel>>? _notesFuture) in the TaskDetailScreen
State, initialize it once in initState with _notesFuture =
context.read<TaskViewModel>().getNotesForTask(taskId), and change the
FutureBuilder to use future: _notesFuture; after a successful createNote (or
other explicit refresh events) reassign _notesFuture =
context.read<TaskViewModel>().getNotesForTask(taskId) and call setState to
update—this prevents automatic refetch/flicker on unrelated rebuilds.

src/lib/features/tasks/viewmodel/task_viewmodel.dart-162-167 (1)

162-167: ⚠️ Potential issue | 🟠 Major

Clear stale tasks when there is no authenticated user.

If the session is missing, fetchTasks() returns without clearing _tasks, so a logged-out or switched user can still see the previous user’s in-memory task list.

Proposed fix

     final user = supabase.auth.currentUser;
     
-    if (user == null) return; 
+    if (user == null) {
+      _tasks.clear();
+      notifyListeners();
+      return;
+    }

Also applies to: 211-213

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/tasks/viewmodel/task_viewmodel.dart` around lines 162 - 167,
When fetchTasks() finds no authenticated user
(Supabase.instance.client.auth.currentUser == null), it should clear the
in-memory task list and update observers instead of returning early; update the
fetchTasks() method to set _tasks = [] (or clear the collection) and call
notifyListeners() before returning. Apply the same change to the other fetch
path referenced in the file (the second early-return block around the later
fetchTasks logic) so that both locations clear _tasks and notifyListeners when
user == null.

src/lib/features/tasks/viewmodel/task_viewmodel.dart-169-206 (1)

169-206: ⚠️ Potential issue | 🟠 Major

Hydrate category and tags from the persisted schema.

fetchTasks() selects * and reads item['category'], but task creation writes category_id; fetched tasks will fall back to General. Tags are never populated either, so tag filtering over t.tags cannot work for persisted tasks.

Proposed direction

       final data = await supabase
           .from('task')
-          .select('*')
+          .select('''
+            *,
+            category:category_id(id, name, color_code, profile_id),
+            tags:task_tag(tag(id, name, color_code, profile_id))
+          ''')
           .eq('profile_id', user.id) 
           .order('create_at', ascending: true);

Then build CategoryModel from the joined category object and List<TagModel> from the joined tag rows instead of using placeholder category data and empty tags.

Also applies to: 259-264

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/tasks/viewmodel/task_viewmodel.dart` around lines 169 - 206,
fetchTasks() currently reads item['category'] incorrectly (only category_id was
persisted) and never populates TaskModel.tags, so tasks fall back to a
placeholder CategoryModel and empty tags. Fix by updating the Supabase query in
fetchTasks() to include the joined category and tags (e.g. select with
category(*) and tags(*) or the intermediate task_tag join), then when iterating
items construct CategoryModel from the returned category object fields (id,
name, color_code, profile_id) instead of the hardcoded values and build a
List<TagModel> from the returned tag rows (mapping each tag row to TagModel) and
assign it to TaskModel.tags; keep using existing TaskModel, CategoryModel and
TagModel constructors to map the fields and preserve date/priority parsing as
before.

src/lib/features/user/viewmodel/user_profile_viewmodel.dart-16-16 (1)

16-16: ⚠️ Potential issue | 🟠 Major

Default profile loading should use real data.

useMockData defaults to true, so any production call site that omits the argument will show the hardcoded Alex Thompson profile instead of the signed-in user. Make mock mode opt-in and ensure the production provider wiring does not pass true.

Proposed fix

-  UserProfileViewModel({this.useMockData = true});
+  UserProfileViewModel({this.useMockData = false});

Also applies to: 30-34

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/user/viewmodel/user_profile_viewmodel.dart` at line 16, The
constructor default for UserProfileViewModel currently sets useMockData = true,
causing real callers to load mock profiles; change the default to false so mock
mode is opt-in (i.e., UserProfileViewModel({this.useMockData = false})), update
any related factory/constructors or providers that currently pass true to
instead opt-in explicitly, and scan the other constructor/initialization usages
referenced around the UserProfileViewModel class (the similar block at lines
~30-34) to ensure they do not default to or pass true inadvertently.

src/lib/features/tasks/view/screens/create_task_screen.dart-167-172 (1)

167-172: ⚠️ Potential issue | 🟠 Major

Remove demo defaults and dispose the controllers.

The create screen currently opens with "Team Meeting" and a sample description, which can create accidental test data. Since these controllers are owned by the state object, they should also be disposed.

Proposed fix

-  final TextEditingController _nameController = TextEditingController(
-    text: 'Team Meeting',
-  );
-  final TextEditingController _descController = TextEditingController(
-    text: 'Discuss all questions about new projects',
-  );
+  final TextEditingController _nameController = TextEditingController();
+  final TextEditingController _descController = TextEditingController();
+
+  `@override`
+  void dispose() {
+    _nameController.dispose();
+    _descController.dispose();
+    super.dispose();
+  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/tasks/view/screens/create_task_screen.dart` around lines 167
- 172, Remove the hardcoded demo values from the TextEditingController instances
by initializing _nameController and _descController without the text: parameter
so they start empty, and add a dispose override in the State class to call
_nameController.dispose() and _descController.dispose(); ensure the dispose
method also calls super.dispose(). These symbols to change are the
TextEditingController fields named _nameController and _descController and the
State's dispose() method for the CreateTaskScreen widget.

src/lib/features/tasks/view/screens/create_task_screen.dart-66-127 (1)

66-127: ⚠️ Potential issue | 🟠 Major

Persist all submitted task fields.

description and tags are accepted by submitTask() and passed from the UI, but only title/status/priority/profile/category/date are inserted. This drops the user’s description and selected tags on every created task.

Proposed direction

-    await _supabase.from('task').insert({
+    final insertedTask = await _supabase.from('task').insert({
       'title': taskName.trim(),
-      //'description': description.trim(), // Tui mở comment cái này ra cho ông luôn
+      'description': description.trim(),
       'status': 0,
       'priority': priorityId,
       'profile_id': user.id,
       'category_id': categoryId, // Dùng ID thực tế từ UI
       'create_at': scheduledDateTime.toIso8601String(),
-    });
+    }).select('id').single();
+
+    // Also persist `tags` into the task/tag join table used by the schema.
+    // Example:
+    // await _supabase.from('task_tag').insert(
+    //   tags.map((tag) => {'task_id': insertedTask['id'], 'tag_id': tag.id}).toList(),
+    // );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/features/tasks/view/screens/create_task_screen.dart` around lines 66
- 127, The insert currently omits the passed description and tags; update the
insert in submitTask(...) (the _supabase.from('task').insert call) to include
'description' (use description.trim() or null-guard if empty) and persist 'tags'
(serialize to the DB format your table expects, e.g., a JSON array or text
array—convert List<dynamic> tags to List<String> or jsonEncode(tags) as needed)
alongside the existing fields so all submitted task fields are saved.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes